REMARKS 

Claims 1-18 remain in the application. Claims 4, 7-8 and 10-11 have been amended. 

Claim Rejections under 35 U.S.C. 102(e) and 103(a) 

Claims 13-18 were rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
No. 6,605,120 to Fields et al. ("Fields"). Claims 1-3, 5-7 and 10 were rejected under 35 U.S.C. § 
103(a) as being unpatentable over Fields in view of U.S. Publication No. 2002/0133516 to Davis 
et al. ("Davis"). Claims 4, 8-9, and 1 1-12 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Fields in view of Davis in view of U.S. Publication No. 2002/00069175 to 
Burich ("Burich"). In discussing the Davis and Burich references, Applicants are making no 
admission that the filing dates of these published applications predate the invention dates of the 
present application. 

Claim 13 

Fields concerns the use (or rather reuse) of material from another's web-site on one's 
own web-site (see Col. 1, lines 51-53). One problem with such a system is that if a second web- 
site uses the content of a first web-site (e.g., a news article), then revenue that would have been 
generated by viewing the article at the first web-site is lost (see Col. 1, line 59 to Col. 2, line 5). 
In Fields an article is displayed with the ads that the originator intended to be shown with the 
article (see Col. 5, lines 35-41). Policy rules may be added to insure what links are to be 
included with the re-cast article (See Col. 6, line 61 to Col. 7, line 15). 

In claim 13, an incoming XML data element is parsed to determine the source web-page, 
the destination web-page, and the data to be received by the destination web-page. A pretoken is 
created from this XML data element and it is concatenated to a token to form a modified XML 
data element (MXDE). The MXDE can then be displayed using a web browser. The Office 

DC01 591932 v1 



6 



Action quotes large portions of the claim and states that they can be found in Fields to support a 
§ 102(e) rejection. Applicants respectfully disagree. The claim states that an incoming XML 
data element is parsed to determine the destination web-page. Such a feature is not shown in 
Fields. To show this feature the Office Action relies on Col. 5, lines 15-21 ("Using the filters 
and the retrieved HTML page, the pass through publisher 101 parses the HTML source for 
desired components of the page. Typically, this is the title of the article, the ad banner or banners 
and the article text itself, although other items on the page are potentially desirable. These pieces 
of content are then recast into a new web page by means of an HTML template 121 that matches 
the look and feel of the hosting Web site.") and Col. 3, lines 5-10 ("First, a set of pages, possibly 
a single page, is retrieved from a content provider web server. Next, the web page is parsed to 
identify a set of selectable content elements. Next, a representation of the original web page is 
presented in a user interface, wherein the selectable content elements are demarcated. The user 
will select some of the elements for inclusion in the filter through the user interface, whereby the 
tool will indicate the selected content elements for inclusion in the filter."). Nothing in this text 
describes determining the destination web page from an incoming XML data element. 

To further support its rejection based on Fields, the Office Action relies on Col. 17, lines 
45-64 ("Once the web page 901 is retrieved by the pass through agent 91 1 at the hosting server 
905, the XML tag is identified through the parsing process. The data boundaries, data ID and 
policy data are extracted and are used to assemble the recasted page. If a policy ID is specified, 
the corresponding policy is retrieved from the policy database. Alternatively, if no policy is 
specified in the tag, the URL from which the web page was retrieved is used to retrieve the 
appropriate policy. The policy data, both from the tag and from the policy in the policy database, 
is used to determine whether the hosting site has permission to recast the web page to the 
requesting client. The client specific data which is included in the client request such as IP 
address is matched against the policy for web data or publisher. Other types of client specific 
data include client operating system, browser manufacturer and version, browser capabilities, 
e.g., JavaScript, StyleSheets, domain and the referer document which indicates the source URL 
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from which the link originated. If the client specific data is not contained in the initial request, 
the hosting server can make a query to the client for the needed data, e.g., authentication."). 

As stated above, the originator of content can set policies for how its data will be 
displayed at a second site. This is performed by the XML tag 909 referred to in the text above 
(see Col. 7, lines 3 1 -37). The XML tag 909 defines the boundaries of the data for which a 
policy applies, and the policy itself. Nothing in the XML tag 909 refers to identification of the 
source page or the destination page. Since a feature of claim 13 is not taught nor suggested by 
Fields, reconsideration and withdrawal of the rejection of claims 13-18 under 35 U.S.C. § 102 is 
respectfully requested. 

Claim 1 

In claim 1, a console engine receives a request for a web page and communicates with an 
XML repository that has a plurality of parts of web pages, a plurality of HTML/XML templates, 
and an application handler registered to modify one of the templates. With an extracted template 
for the requested web page, the use of the application handler generates a part of the web page 
incorporates it into the template to form the web page (e.g., that can then be sent back to the user 
that sent a request for a web page). 

The feature of a "console engine" was added to claim 1 in the previous Amendment. The 
present Office Action repeats the rejection of claim 1 under 35 U.S.C. § 103(a) stating that Fields 
in combination with Davis teaches all of the features of claim 1. Then at page 6 of the Office 
Action, it states that "Fields in view of Davis does not expressly teach, but Burich teaches 
"console API" (para. 30)." Since the console engine feature is incorporated into Claim 1, it 
would appear that the Office Action is ambiguous as to whether the feature is shown in Fields in 
combination with Davis or not. Since the current rejection, except for the "Response to 
Arguments" section, is a verbatim copy of the previous Office Action, it is assumed that the 
Examiner agrees that the console feature of claim 1 is not found in Fields in combination with 

DC01 591932 v 1 



8 



Davis. If that is not the case, Applicants respectfully request that the Examiner point out support 
for rejecting all of the features of claim 1 based on only the Fields and Davis references. 

Burich refers to a system for sharing information. In Burich, specifications on food 
products are stored locally and can be presented to a user when is logs in from a remote 
computer. Paragraph 30 of Burich, states "XML specifications may be manually formatted as 
XML documents or, generated automatically from a non-XML format specification. Typically, 
specifications are stored, currently, as text or in a relational database form and parsed 
information may include sections for a header, a reference, property and text. An application 
programming interface (API) may be created to perform automatic specification migration from 
data organized into predefined fields. After parsing data, a participant provides the parsed data in 
predefined specification textual fields that may include time/data stamps. The API then converts 
the parsed data to an XML document." Paragraph 30 of Burich is referring to how an API is 
used to take previously parsed data and combine it into an XML document. Claim 1 states that a 
console engine is to extract a template and an application handler that is registered to modify the 
template to generate a part of the requested web page. Claim 1 further states that the console 
engine is to receive message to be sent to web pages. Burich, in particular paragraph 30, is silent 
as to these features. As to claims 7 and 10, each claim refers to a console engine and accessing a 
template for the desired web-page and application handlers that are associated with the template 
to generate a plurality of parts for the web page. Such features are not shown or suggested in 
Burich as well. 

Since features of the pending claims are neither shown nor suggested by the Fields, Davis 
or Burich references, reconsideration and withdrawal of the rejection of claims 1-18 under 35 
U.S.C. §§ 102(e) and 103(a) is respectfully requested. 
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CONCLUSION 



For all the above reasons, the Applicant respectfully submits that this application is in 
condition for allowance. A Notice of Allowance is earnestly solicited. 

The Examiner is invited to contact the undersigned at (202) 220-4255 to discuss any 
matter concerning this application. The Office is hereby authorized to charge any additional fees 
or credit any overpayments under 37 C.F.R. § 1.16 or § 1.17 to Deposit Account No. 1 1-0600. 



KENYON & KENYON 
1500 K Street, NW 
Suite 700 

Washington DC, 20005 
(202)220-4200 telephone 
(202) 220-4201 facsimile 

DC:591932vl 



Respectfully submitted, 



KENYON & KENYON 




By: 




Shawn W. O'Dowd 
Reg. No. 34,687 
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